IBIS Macromodel Task Group Meeting date: 17 Jan 2012 Members (asterisk for those attending): Agilent: * Fangyi Rao * Radek Biernacki Altera: David Banas Ansys: Samuel Mertens * Dan Dvorscak * Curtis Clark Arrow Electronics: Ian Dodd Cadence Design Systems: Terry Jernberg * Ambrish Varma Celsionix: Kellee Crisafulli Cisco Systems: Mike LaBonte Ashwin Vasudevan Syed Huq Ericsson: Anders Ekholm IBM: Greg Edlund Intel: Michael Mirmak LSI Logic: Wenyi Jin Mentor Graphics: * John Angulo Zhen Mu * Arpad Muranyi Vladimir Dmitriev-Zdorov Micron Technology: * Randy Wolff NetLogic Microsystems: Ryan Couts Nokia-Siemens Networks: * Eckhard Lenski QLogic Corp. * James Zhou Sigrity: Brad Brim Kumar Keshavan * Ken Willis SiSoft: * Walter Katz Todd Westerhoff Doug Burns Snowbush IP: Marcus Van Ierssel ST Micro: Syed Sadeghi Teraspeed Consulting Group: Scott McMorrow * Bob Ross TI: Casey Morrison Alfred Chong Vitesse Semiconductor: Eric Sweetman Xilinx: Mustansir Fanaswalla The meeting was lead by Arpad Muranyi ------------------------------------------------------------------------ Opens: -------------------------- Call for patent disclosure: - None ------------- Review of ARs: - None ------------- New Discussion: Quick question from Arpad regarding which BIRDS to discuss: - Arpad: Should we focus entirely on Analog BIRD proposals or look at 121.1 and 124.1, which might require less discussion? - Walter: 121.1 is ready for review. 124.1 will be resubmitted. - Arpad: Resubmitted as 124.2? - Walter: yes. - Bob: Does it involve substantial changes? Should it be a new BIRD? - Walter: Agree with Bob, it will be submitted as a new BIRD. - Arpad: We may slip 121.1 in at some point, but we'll defer the other. Analog BIRD discussion: - Arpad: Last week we agreed to table Walter's new tree syntax proposal. - Arpad: Continuing the discussion... (shared his BIRD comparison slides). - These slides will be used to capture our discussions/questions/info. - Two new slides: - one for SiSoft intrinsic models, one for Cadence's BIRD 144 - Walter, do you want to discuss your proposals? - Walter: (sharing draft email with proposed template models) - s4p example covers On Die S params. - Thevenin examples Tx/Rx can replace typical BIRD 122 models. - Thevenin examples can handle the classic I/V IBIS models. - Reserved Model templates get their values from model specific parameters with pre-defined names. - If these are included in BIRD 116, BIRD122 would be withdrawn. - Bob: This is a lot to absorb. - Are there predefined reserved parameters for Thevenin templates? - Aren't these "reserved" names for model specific parameters? - This is a hard coded topology, right? - Walter: Agreed, these are 4 hardcoded shortcuts to BIRD 116 circuits. - Arpad: Shouldn't these be reserved parameters? - How can you have model specific parameters with reserved names? - Ambrish: So you're introducing a Reserved Model concept. - Walter: Yes, but BIRD 144 also contains a list of allowed Touchstone files. - Ambrish: They're two separate issues. - Can you use a Reserved Model without AMI? - Walter: We can remove "AMI" from Reserved Model names. - The proposal is general. - Ambrish: We could theoretically end up with many new Reserved Models. - Walter: Yes, over time more could be added if they're justified. - Ambrish: BIRD 116 can already handle all of this. - Walter: The usage of Reserved Models is optional. - The model maker can build their own general model if they want. - Radek: I question the need for this predefined subcircuit model. - Walter: They're simply 4 templates. - Radek: The concept is clear, however, - Reserved Models may not be sufficient in the future. - The concept is not necessary - Arpad: (returning to his summary slides and reviewing bullet points) - Proposal could reduce file management burden. - Proposal provides a shorthand notation. - No one has yet discussed one additional issue - performance. - Performance advantage because the tool knows it's a fixed topology? - Closed form solution, etc., for fixed topology? - Radek: No real performance advantage for these small LTI circuits. - Ken: When we go "hard-coded" we end up with an explosion of new things. - We've been on this path before. - Original IBIS models -> insufficient -> invented External Models. - This would follow the same path. - Walter: AMI assumptions are all covered. - AMI assumes impulse response which assumes LTI. - These Reserved Models could describe all such models. - Ken: If we support these we'll be adding them forever. - Arpad: We had two solutions - general and hard coded topology. - Is there an intermediate solution with a Reserved subcircuit name? - Ken: Circuit descriptions are essentially a solved problem. - We have ISS support, so why should this committee reinvent the wheel? - Bob: Is this Reserved Modeling optional? - Walter: Yes, the Reserved Models are just templates. - Ken: This is not optional for the EDA tool. - The EDA tool would have to support these hard coded models. - Bob: Reserved Models need not be related to AMI? - Arpad (back to Walter's email) - This works when the parameters are there in the AMI file. - How does it work if not tied to AMI? - Doesn't it assume the params come from the AMI file? - Walter: Yes, that is correct. I forgot about that. - This shortcut is only for AMI use. - Walter: The Thevenin circuits can cover every LTI, constant diff impedance. - Complete representation of any classic IBIS LTI model. - Vendors are doing this already, they're using S4P for On Die S-params. - Randy: Where is the topology defined? - Ken: The EDA tools have to know what it is. - Arpad: We would have to define it in the spec. - Arpad: (Comparing Walter's proposal and BIRD 144) - Neither approach gives a functional advantage (BIRD 116 is general). - Both offer reductions in file management issues for model makers. - Both offer syntax shortcuts. - Corner issues might still need to be addressed. - BIRD 144 is a short cut to a Touchstone file. - So, you can't reject one proposal but not the other for "hard coding." - Ambrish: Touchstone is more general. - Radek: Arpad is right (regarding both proposals being shortcuts). - Bob: The direct connection to Touchstone is general. - But knowing it's a direct connection to a Touchstone file is better. - Radek: The best shortcut proposal is direct to Touchstone. - Bob: Shortcut to Touchstone supports s6P, s8P, etc. - Radek: Solution should be more general than to rely on the AMI file. - Walter: These Reserved Models are optional. - Radek/Ken: The tools would "have" to support these hard coded Models. - Arpad: Walter, could you summarize the benefits of your proposal? - Walter: Arpad, your slide covered the advantages nicely. - Covers all On Die S-params. - Gets rid of redundant files (simplifies model maker's life) - Model maker need only add one small section to the IBIS file. - Ambrish: I suggest we keep this proposal separate from BIRD 116. - As Walter said, BIRD 116 is the most general. - Walter: I'm fine with a separate approval process. - Arpad: I agree. - Bob: question for Walter - We have a pre-defined model but it uses model specific variables? - Randy: Only the topology itself is hard coded. - James: We shouldn't have model specific parameters with reserved names. - Radek: This is a misuse of "model specific." - Walter: When someone programs an AMI model, chooses strength, tap coefficients, registers on Tx or Rx model, there becomes a dependency table (BIRD124) where for each programming it determines the impedances, C_comps, etc. that go into the analog model. - So, with Tx with 128 strengths, must create 128 models with 128 model selectors and 128 AMI files. - Ambrish: Shouldn't the parameters be reserved? - Walter: Making these parameters reserved makes them only useful with these 4 reserved models, so doesn't see the need. ------------- Next meeting: 24 Jan 2012 12:00pm PT Next agenda: 1) Task list item discussions ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives